1. Field of the Invention
The present invention relates to Internet Key Exchange (IKE), which is a protocol for generating an encryption key for an IP Security Protocol (IPsec), and more particularly, to a Diffie-Hellman key agreement.
2. Description of the Related Art
FIG. 1 is a diagram illustrating a conventional method of securing Internet communications according to IP Security Protocol (IPsec). IPsec is a communications protocol that guarantees the security of Internet communications. IPsec, which is loaded onto an IP layer, for example, a third layer of a reference model, enables two hosts, which are willing to communicate with each other through the Internet, to transmit or receive secured data to/from each other. The format of encryption or authentication according to IPsec is called Security Association (SA). IPsec uses Internet Key Exchange (IKE), which is a mixture of Internet Security Association & Key management Protocol (ISAKMP), Oakley, and Secure Key Exchange MEchanism (SKEME), to generate an encryption key. IKE adopts a packet format appropriate for key exchange and key authentication from ISAKMP, a key exchange mode from Oakley, and a method of encrypting a public key from SKEME.
Referring to FIG. 1, an encryption key is generated on an application layer of an open systems interconnection (OSI) reference model according to IKE. This type of method to generate an encryption key according to IKE can be divided into two different phases, i.e., a first phase in which an IKE encryption key is generated and a second phase in which an IPsec encryption key is generated. The first phase is implemented to protect the second phase. In the first phase, SA having an ISAKMP format (i.e., ISAKMP SA) is generated. The second phase is implemented to protect the IPsec communications. In the second phase, (Ipsec SA) ISAKMP SA is generated. IPsec SA is used to protect data transmitted to another host. Such protected data is transmitted to the other host in the form of (data)IPsec SA passing through an IPsec tunnel.
FIG. 2 is a flowchart of the first phase of the conventional method of generating an IKE encryption key. Referring to FIG. 2, a public key and a private key, which serve as factors in calculating an IKE encryption key, are renewed whenever the IKE encryption key is calculated, in order to guarantee perfect forward secrecy (PFS) of the IKE encryption key. PFS means that previous encryption keys will never be disclosed even though a current encryption key is accidentally disclosed.
FIG. 3 is a flowchart of the second phase of the conventional method of generating an IKE encryption key. Referring to FIG. 3, a public key and private key are renewed whenever a packet 30 is transmitted for calculating an IPsec encryption key. As described above, in both the first and second phases, the public key and the private key should be periodically renewed. In the process of renewing the public key and the private key, a Diffie-Hellman key agreement protocol is used for key agreement.
FIG. 4 is a diagram illustrating a conventional method of generating an encryption key according to the Diffie-Hellman key agreement protocol. Referring to FIG. 4, two hosts have private keys Xi and Xj, respectively, that will never be disclosed. The private keys Xi and Xj are prime numbers. Each of the two hosts has a public key Yi or Yj, which are disclosed in the process of being transmitted between the two hosts. The public key Yi or Yj is calculated by substituting the private key Xi or Xj into a corresponding equation shown in FIG. 4. Then, the two hosts exchange their public keys Yi and Yj. Thereafter, each of the hosts calculates a shared key K by substituting the public key Yi or Yj that it receives from the other host and its own private key Xi or Xj into a corresponding equation shown in FIG. 4. Thereafter, an encryption key is generated using the shared key K. However, since the equations used to calculate the public keys Yi and Yj contain an exponential function, the number resulting from the calculation is very large, and accordingly, because of the complex calculations required, it takes a while to obtain the public keys Yi and Yj and their respective shared keys.
FIG. 5 is a diagram illustrating problems of the conventional method of generating an IKE encryption key. More specifically, FIG. 5 illustrates three different scenarios. The left portion of FIG. 5 illustrates a case where the period of connecting two hosts is longer than the period of renewing an encryption key. In this case, the encryption key is periodically renewed (i.e., key 1 is renewed to key 2) while a connection 1 between the two hosts is maintained, and thus, PFS is guaranteed. The middle portion of FIG. 5 illustrates a case where the period of connecting the two hosts is shorter than the period of renewing the encryption key. In this case, a previous encryption key, key 1′, is kept valid without being renewed even after the connection between two hosts is reset (i.e., connection 1′ and connection 2′), and thus, PFS cannot be guaranteed. Therefore, in order to guarantee PFS, the period of renewing the encryption key should be shortened. However, the shorter the period of renewing the encryption key, the higher the frequency of calculating public keys and the larger the work load for each of the hosts.
The right portion of FIG. 5 illustrates the next version of IKE, i.e., IKEv2. IKEv2 adopts an algorithm, in which an encryption key, Key 1′″ is maintained as long as a connection between the two hosts is maintained and is renewed whenever the connection between the two hosts is reset. In this case, whenever the connection between the two hosts is reset, public keys (i.e., connection 1″ and connection 2″) key 1″ and key 2″ of the two hosts should be recalculated, which results in an increasing workload for each of the two hosts.